02_Multi-Region 아키텍처 트레이드오프
문제
글로벌 서비스를 Multi-Region으로 구성할 때, 단순히 여러 리전에 동일한 인프라를 복제하는 것만으로는 부족합니다.
데이터 정합성(eventual consistency vs strong consistency), 네트워크 레이턴시, 그리고 각 리전의 장애 격리(failure isolation)라는 세 가지 요구사항이 서로 충돌하는 상황에서, 어떤 트레이드오프를 고려해야 하나요?
특히 "사용자 프로필 정보"와 "실시간 주문 데이터"처럼 특성이 다른 데이터를 어떻게 다르게 다룰지, 아키텍처 설계 관점에서 설명해주세요.
답안
핵심: CAP 정리와 비용의 균형
Multi-Region 아키텍처에서 일관성(Consistency), 가용성(Availability), 분할 내성(Partition Tolerance) 세 가지를 동시에 완벽히 만족시킬 수 없습니다(CAP 정리). SA는 데이터 특성에 따라 어떤 속성을 우선할지 결정해야 합니다.
1. 세 가지 요구사항의 충돌
| 요구사항 | 강화하면 | 약화되는 것 | 비용 영향 |
|---|---|---|---|
| 데이터 정합성 | 동기식 복제 필요 | 레이턴시 증가, 가용성 저하 | 복제 비용 증가 |
| 낮은 레이턴시 | 로컬 리전에서 처리 | 정합성 보장 어려움 | 리전별 인프라 비용 |
| 장애 격리 | 리전 간 독립성 | 데이터 동기화 복잡도 증가 | 운영 복잡도 증가 |
물리적 한계: 서울-버지니아 간 네트워크 왕복 시간은 약 200ms입니다. 동기 복제를 하면 모든 쓰기 요청에 최소 200ms가 추가됩니다.
2. 데이터 특성별 전략
사용자 프로필 (읽기 많음, 변경 적음)
특성: 읽기 99% / 쓰기 1%, 잠시 이전 데이터 봐도 무방
전략: Eventual Consistency + Read Replica
- 각 리전에 Read Replica 배치 → 로컬 읽기로 낮은 레이턴시
- 프로필 변경 시 Primary로 쓰기 → 비동기로 복제 (1초 이내)
- 복제 지연 동안 다른 리전에서 이전 데이터 보일 수 있음 → 비즈니스적으로 허용 가능
AWS 구현: Aurora Global Database (비동기 복제, 1초 미만 지연)
실시간 주문 데이터 (쓰기 중요, 정합성 필수)
특성: 읽기/쓰기 빈번, 재고/결제와 연동, 불일치 시 금전적 손실
전략: Strong Consistency + Single Primary 또는 지역 파티셔닝
옵션 A: Single Primary
- 모든 쓰기를 한 리전(예: 서울)에서 처리
- 다른 리전 사용자는 쓰기 시 레이턴시 감수
- 장점: 정합성 보장 / 단점: Primary 리전 장애 시 쓰기 불가
옵션 B: 지역 파티셔닝
- 한국 사용자 주문 → 서울 Primary
- 미국 사용자 주문 → 버지니아 Primary
- 각 리전이 해당 지역의 Primary 역할
- 장점: 로컬 쓰기 가능 / 단점: 글로벌 집계 복잡
3. 의사결정 프레임워크
질문 1: 불일치 시 비즈니스 영향이 큰가?
├─ 예 (결제, 재고) → Strong Consistency
└─ 아니오 (프로필, 설정) → Eventual Consistency
질문 2: 읽기/쓰기 비율은?
├─ 읽기 위주 → Read Replica 활용
└─ 쓰기 위주 → Primary 위치 전략 수립
질문 3: 사용자가 지역적으로 분산되어 있는가?
├─ 예 → 지역 파티셔닝 검토
└─ 아니오 → 단일 리전 Primary로 충분
4. 결론: 데이터 유형별 정리
| 데이터 유형 | 정합성 수준 | 복제 방식 | 레이턴시 | 비용 |
|---|---|---|---|---|
| 사용자 프로필 | Eventual | 비동기 | 낮음 | 낮음 |
| 세션/캐시 | Eventual | 로컬 | 매우 낮음 | 낮음 |
| 실시간 주문 | Strong | 동기 | 높음 | 높음 |
| 금융 거래 | Strong | 동기 | 높음 | 매우 높음 |
| 로그/분석 | Eventual | 비동기 | 무관 | 낮음 |
핵심 메시지: 모든 데이터에 동일한 전략을 적용하지 말 것. 비즈니스 요구사항에 따라 데이터를 분류하고, 각각 적절한 정합성 수준을 적용해야 합니다. SA의 역할은 "모든 것을 완벽하게"가 아니라 "적절한 트레이드오프를 선택"하는 것입니다.
심화 답안
1. Multi-Region 아키텍처의 근본적 딜레마
Multi-Region 구성의 목적은 크게 세 가지입니다:
- 글로벌 사용자에게 낮은 레이턴시 제공
- 리전 장애 시에도 서비스 지속
- 데이터 일관성 유지
그러나 이 세 가지는 물리적으로 동시에 완벽히 달성할 수 없습니다.
CAP 정리(CAP Theorem)란?
분산 시스템에서 다음 세 가지 속성을 동시에 모두 만족시킬 수 없다는 이론입니다:
- Consistency(일관성): 모든 노드가 동일한 데이터를 봄
- Availability(가용성): 모든 요청이 응답을 받음
- Partition Tolerance(분할 내성): 네트워크 분할 상황에서도 시스템이 동작
네트워크 분할은 분산 시스템에서 불가피하므로, 실질적으로 C와 A 중 하나를 선택해야 합니다.
PACELC 정리란?
CAP의 확장으로, 네트워크가 정상일 때도 트레이드오프가 존재함을 설명합니다:
- Partition 발생 시: Availability vs Consistency 선택
- Else(정상) 상황: Latency vs Consistency 선택
즉, 평상시에도 낮은 레이턴시를 원하면 일관성을 양보해야 합니다.
2. 세 가지 요구사항의 상충 관계
데이터 정합성 vs 레이턴시
Strong Consistency (동기 복제)
┌─────────┐ 쓰기 요청 ┌─────────┐
│ Seoul │ ───────────────→ │ Primary │
│ Client │ │ (Seoul) │
└─────────┘ └────┬────┘
│
동기 복제 (완료 대기)
│
┌────────────────────┼────────────────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Tokyo │ │ Singapore│ │ Virginia │
│ Replica │ │ Replica │ │ Replica │
└──────────┘ └──────────┘ └──────────┘
모든 리전 복제 완료 후 응답 → 레이턴시 = 가장 느린 리전 RTT(Round Trip Time : 왕복 시간)
Eventual Consistency (비동기 복제)
┌─────────┐ 쓰기 요청 ┌─────────┐
│ Seoul │ ───────────────→ │ Primary │ → 즉시 응답
│ Client │ ←─────────────── │ (Seoul) │
└─────────┘ 응답 └────┬────┘
│
비동기 복제 (백그라운드)
│
┌────────────────────┼────────────────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Tokyo │ │ Singapore│ │ Virginia │
│ (지연) │ │ (지연) │ │ (지연) │
└──────────┘ └──────────┘ └──────────┘
Primary 저장 후 즉시 응답 → 낮은 레이턴시, 일시적 불일치 허용
동기 복제(Synchronous Replication)란?
쓰기 작업이 모든(또는 정족수의) 복제본에 반영된 후에야 클라이언트에 응답하는 방식입니다. 데이터 일관성이 보장되지만, 가장 느린 복제본의 응답 시간만큼 레이턴시가 증가합니다. 리전 간 네트워크 지연이 수십~수백 ms이므로, 글로벌 동기 복제는 상당한 지연을 유발합니다.
비동기 복제(Asynchronous Replication)란?
Primary에 쓰기가 완료되면 즉시 응답하고, 복제본으로의 전파는 백그라운드에서 진행하는 방식입니다. 레이턴시는 낮지만, 복제 지연(Replication Lag) 동안 각 리전이 서로 다른 데이터를 볼 수 있습니다.
Replication Lag(복제 지연)이란?
Primary와 Replica 간의 데이터 동기화 시간 차이입니다. 비동기 복제에서는 수 ms에서 수 초까지 발생할 수 있으며, 네트워크 상태나 부하에 따라 변동합니다. 이 시간 동안 Replica에서 읽으면 "과거 데이터"를 보게 됩니다.
장애 격리 vs 데이터 동기화
장애 격리(Failure Isolation)란?
한 리전의 장애가 다른 리전에 영향을 미치지 않도록 설계하는 것입니다. 각 리전이 독립적으로 운영될수록 격리는 강해지지만, 데이터 동기화는 어려워집니다.
강한 격리 (Cell-based Architecture):
- 각 리전이 독립된 데이터 저장소 보유
- 리전 간 의존성 최소화
- 장애 시 해당 리전만 영향
- 단점: 데이터 동기화 복잡, 글로벌 뷰 어려움
약한 격리 (Centralized Primary):
- 단일 Primary 리전이 모든 쓰기 처리
- 데이터 일관성 확보 용이
- 단점: Primary 장애 시 전체 쓰기 불가
Cell-based Architecture란?
시스템을 독립적인 "셀"로 분할하여 각 셀이 자체적으로 완전한 기능을 수행하도록 설계하는 방식입니다. 한 셀의 장애가 다른 셀에 전파되지 않아 "폭발 반경(Blast Radius)"을 제한합니다. AWS, Netflix 등 대규모 서비스에서 채택하는 패턴입니다.
3. 데이터 특성별 전략: 사용자 프로필 vs 실시간 주문
사용자 프로필 정보
특성 분석:
- 읽기:쓰기 비율이 높음 (대부분 조회)
- 변경 빈도 낮음 (프로필 수정은 가끔)
- 잠시 이전 데이터를 봐도 비즈니스 영향 적음
- 전 세계 어디서든 빠른 조회 필요
권장 아키텍처:
┌──────────────────────────────────────────────────────────┐
│ Global Database │
│ (Aurora Global Database) │
├──────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ 비동기 복제 ┌─────────────┐ │
│ │ Seoul │ ←───(~1초 이내)──→│ Virginia │ │
│ │ Primary │ │ Replica │ │
│ │ (R/W) │ │ (R only) │ │
│ └─────────────┘ └─────────────┘ │
│ │ │ │
│ │ ┌─────────────┐ │ │
│ └──────────────│ Singapore │────┘ │
│ │ Replica │ │
│ │ (R only) │ │
│ └─────────────┘ │
└──────────────────────────────────────────────────────────┘
적용 전략:
- Eventual Consistency 허용: 프로필 변경 후 다른 리전에서 최대 수 초간 이전 데이터 노출 가능
- Read Replica 활용: 각 리전에 읽기 전용 복제본 배치
- 캐싱 적극 활용: CloudFront + ElastiCache로 읽기 부하 분산
- 쓰기는 Primary로: 변경 요청은 Primary 리전으로 라우팅
Read Replica란?
Primary 데이터베이스의 읽기 전용 복제본입니다. 쓰기는 Primary에서만 가능하고, 읽기 트래픽을 분산하여 Primary의 부하를 줄입니다. Multi-Region 배치 시 각 리전 사용자에게 낮은 읽기 레이턴시를 제공합니다.
Aurora Global Database란?
AWS Aurora의 Multi-Region 기능으로, 하나의 Primary 리전과 최대 5개의 Secondary 리전을 구성합니다. 복제 지연이 보통 1초 미만이며, Primary 장애 시 Secondary를 Primary로 승격할 수 있습니다.
비용 고려사항:
- Read Replica 유지 비용 vs 사용자 경험 향상
- 캐시 히트율 높이면 DB 비용 절감
- 데이터 전송 비용 (리전 간 복제)
실시간 주문 데이터
특성 분석:
- 쓰기 중요도 높음 (주문 누락 불가)
- 정합성 필수 (재고, 결제와 연동)
- 동시성 제어 필요 (같은 상품 동시 주문)
- 금융 거래와 연관 (감사 추적 필요)
권장 아키텍처:
┌────────────────────────────────────────────────────────────────┐
│ 주문 처리 아키텍처 │
├────────────────────────────────────────────────────────────────┤
│ │
│ Seoul User ──→ Seoul Region ──┐ │
│ │ │
│ Tokyo User ──→ Tokyo Region ──┼──→ Primary Region (Virginia) │
│ │ │ │
│ EU User ────→ Frankfurt ──────┘ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ Order DB │ │
│ │ (Primary) │ │
│ │ Strong │ │
│ │ Consistency │ │
│ └─────────────┘ │
│ │ │
│ 동기 복제 (Standby) │
│ ▼ │
│ ┌─────────────┐ │
│ │ Standby │ │
│ │ (Failover) │ │
│ └─────────────┘ │
└────────────────────────────────────────────────────────────────┘
적용 전략:
- Strong Consistency 적용: 주문 데이터는 정합성 우선
- 단일 Primary 쓰기: 모든 쓰기를 한 리전에서 처리하여 충돌 방지
- 동기식 Standby: 장애 대비 동기 복제 (같은 리전 또는 인접 리전)
- 글로벌 라우팅: 쓰기 요청을 Primary로 라우팅 (레이턴시 감수)
Strong Consistency란?
쓰기 완료 후 모든 읽기 요청이 최신 데이터를 반환하는 것을 보장합니다. 분산 시스템에서 이를 달성하려면 동기 복제나 쿼럼 기반 읽기/쓰기가 필요하며, 레이턴시와 가용성에 영향을 줍니다.
Write Conflict(쓰기 충돌)란?
여러 위치에서 동시에 같은 데이터를 수정할 때 발생하는 문제입니다. Multi-Primary 구성에서 두 리전이 동시에 같은 레코드를 수정하면 어느 것이 "정답"인지 결정해야 합니다. 이를 해결하는 방법으로 Last-Write-Wins, 버전 벡터, CRDT 등이 있습니다.
대안: 리전별 파티셔닝
사용자 위치 기반 파티셔닝:
- 한국 사용자 주문 → Seoul Primary
- 미국 사용자 주문 → Virginia Primary
- 각 리전이 해당 사용자의 Primary 역할
- 크로스 리전 조회 시에만 원격 호출
지리적 파티셔닝(Geo-Partitioning)이란?
데이터를 사용자의 지리적 위치에 따라 분할하여 저장하는 방식입니다. 각 리전이 해당 지역 데이터의 Primary가 되어, 로컬 쓰기 레이턴시를 낮추면서도 정합성을 유지할 수 있습니다. 단, 사용자가 다른 지역으로 이동하거나, 글로벌 집계가 필요한 경우 복잡도가 증가합니다.
비용 고려사항:
- 레이턴시 증가로 인한 사용자 경험 저하 vs 데이터 정합성
- Primary 리전 집중에 따른 용량 계획
- 장애 시 복구 비용 (RTO/RPO)
RTO와 RPO란?
- RTO(Recovery Time Objective): 장애 발생 후 서비스 복구까지 허용되는 최대 시간
- RPO(Recovery Point Objective): 장애 시 허용되는 최대 데이터 손실량 (시간 단위)
Strong Consistency를 요구하는 주문 데이터는 RPO가 0에 가까워야 하므로 동기 복제가 필요합니다. 반면 프로필 데이터는 RPO를 수 초~수 분까지 허용할 수 있어 비동기 복제가 가능합니다.
4. 실전 아키텍처 패턴
패턴 1: 데이터 계층 분리
┌─────────────────────────────────────────────────────────┐
│ 데이터 계층 분리 │
├─────────────────────────────────────────────────────────┤
│ │
│ Hot Data (실시간 주문) Cold Data (프로필) │
│ ┌─────────────────────┐ ┌─────────────────────┐│
│ │ - Strong Consistency│ │ - Eventual Consist. ││
│ │ - Single Primary │ │ - Multi Read Replica││
│ │ - 동기 복제 │ │ - 비동기 복제 ││
│ │ - 높은 비용 │ │ - 낮은 비용 ││
│ │ - DynamoDB Global │ │ - Aurora Global ││
│ │ Tables (Strong) │ │ Database ││
│ └─────────────────────┘ └─────────────────────┘│
│ │
└─────────────────────────────────────────────────────────┘
패턴 2: CQRS 적용
CQRS(Command Query Responsibility Segregation)란?
읽기(Query)와 쓰기(Command)를 별도의 모델/저장소로 분리하는 패턴입니다. 쓰기는 정합성이 중요한 Primary에서, 읽기는 최적화된 Read Model에서 처리합니다. Multi-Region에서 쓰기는 중앙에서, 읽기는 각 리전에서 처리하는 구조에 적합합니다.
Command (쓰기) Query (읽기)
│ │
▼ ▼
┌─────────────┐ 이벤트 ┌─────────────┐
│ Primary │ ──발행────────→│ Read Model │
│ Region │ (비동기) │ (각 리전) │
│ (정합성 O) │ │ (낮은 지연) │
└─────────────┘ └─────────────┘
패턴 3: Saga 패턴으로 분산 트랜잭션
Saga 패턴이란?
분산 시스템에서 여러 서비스에 걸친 트랜잭션을 관리하는 패턴입니다. 하나의 큰 트랜잭션을 여러 로컬 트랜잭션으로 분할하고, 실패 시 보상 트랜잭션(Compensating Transaction)을 실행하여 롤백합니다.예: 주문 생성 → 재고 차감 → 결제 → 배송 예약
결제 실패 시: 배송 취소 → 재고 복구 → 주문 취소
5. 의사결정 프레임워크
데이터 특성 분석
│
▼
┌─────────────────────────────────────────────┐
│ 1. 읽기/쓰기 비율은? │
│ - 읽기 위주 → Eventual OK │
│ - 쓰기 위주 → Strong 검토 │
├─────────────────────────────────────────────┤
│ 2. 불일치 시 비즈니스 영향은? │
│ - 낮음 (프로필) → Eventual OK │
│ - 높음 (결제) → Strong 필수 │
├─────────────────────────────────────────────┤
│ 3. 레이턴시 요구사항은? │
│ - 엄격함 → 로컬 처리 + Eventual │
│ - 유연함 → 원격 Primary 허용 │
├─────────────────────────────────────────────┤
│ 4. 장애 시 허용 가능한 동작은? │
│ - 읽기만 가능 → Read Replica 활용 │
│ - 쓰기 필수 → Multi-Primary 또는 │
│ 빠른 Failover 필요 │
└─────────────────────────────────────────────┘
6. 결론
Multi-Region 아키텍처에서 SA가 기억해야 할 핵심
- 만능 해결책은 없다: CAP/PACELC 정리에 따라 트레이드오프는 불가피
- 데이터 분류: 모든 데이터에 같은 전략을 적용하지 말 것
- 비즈니스 요구사항이 기준: 기술이 아닌 비즈니스 영향도로 판단
- 비용 계산: Strong Consistency의 비용(레이턴시, 인프라)을 정량화
| 데이터 유형 | 정합성 수준 | 복제 방식 | 레이턴시 | 비용 |
|---|---|---|---|---|
| 사용자 프로필 | Eventual | 비동기 | 낮음 | 낮음 |
| 세션/캐시 | Eventual | 비동기/로컬 | 매우 낮음 | 낮음 |
| 실시간 주문 | Strong | 동기 | 높음 | 높음 |
| 금융 거래 | Strong | 동기 | 높음 | 매우 높음 |
| 로그/분석 | Eventual | 비동기 | 무관 | 낮음 |
SA의 역할은 "모든 것을 완벽하게"가 아니라 "적절한 트레이드오프를 선택"하는 것입니다. 그 기준은 비즈니스 요구사항과 비용입니다.